The characteristic of software processes, unlike manufacturing ones, is that they have a very\udhigh human-centered component and are primarily based on cognitive activities. As so, each\udtime a software process is executed, inputs and outputs may vary, as well as the process\udperformances. This phenomena is better identified in literature with the terminology of\ud“Process Diversity” (IEEE, 2000). Given the characteristics of a software process, its intrinsic\uddiversity implies the difficulty to predict, monitor and improve it, unlike what happens in\udother contexts. In spite of the previous observations, Software Process Improvement (SPI) is a\udvery important activity that cannot be neglected. To face these problems, the software\udengineering community stresses the use of measurement based approaches such as QIP/GQM\ud(Basili et al., 1994) and time series analysis: the first approach is usually used to determine\udwhat improvement is needed; the time series analysis is adopted to monitor process\udperformances. As so, it supports decision making in terms of when the process should be\udimproved, and provides a manner to verify the effectiveness of the improvement itself.\udA technique for time series analysis, well-established in literature, which has given\udinsightful results in the manufacturing contexts, although not yet in software process ones is\udknown as Statistical Process Control (SPC) (Shewhart, 1980; Shewhart, 1986). The technique\udwas originally developed by Shewhart in the 1920s and then used in many other contexts.\udThe basic idea it relies on consists in the use of so called “control charts” together with their\udindicators, called run tests, to: establish operational limits for acceptable process variation;\udmonitor and evaluate process performances evolution in time. In general, process\udperformance variations are mainly due to two types of causes classified as follows:\ud Common cause variations: the result of normal interactions of people, machines,\udenvironment, techniques used and so on.\ud Assignable cause variations: arise from events that are not part of the process and\udmake it unstable.\udIn this sense, the statistically based approach, SPC, helps determine if a process is stable or\udnot by discriminating between common cause variation and assignable cause variation. We\udcan classify a process as “stable” or “under control” if only common causes occur. More\udprecisely, in SPC data points representing measures of process performances are collected.\udThese values are then compared to the values of central tendency, upper and lower limit of\udadmissible performance variations.\udWhile SPC is a well established technique in manufacturing contexts, there are only few\udworks in literature (Card, 1994; Florac et al., 2000; Weller, 2000(a); Weller, 2000(b); Florence,\ud2001; Sargut & Demirors, 2006; Weller, & Card. 2008; Raczynski & Curtis, 2008) that present\udsuccessful outcomes of SPC adoption to software. In each case, not only are there few cases\udof successful applications but they don’t clearly illustrate the meaning of control charts and\udrelated indicators in the context of software process application.\udGiven the above considerations, the aim of this work is to generalize and put together the\udexperiences collected by the authors in previous studies on the use of Statistical Process\udControl in the software context (Baldassarre et al, 2004; Baldassarre et al, 2005; Caivano 2005;\udBoffoli, 2006; Baldassarre et al, 2008; Baldassarre et al, 2009) and present the resulting\udstepwise approach that: starting from stability tests, known in literature, selects the most\udsuitable ones for software processes (tests set), reinterprets them from a software process\udperspective (tests interpretation) and suggest a recalculation strategy for tuning the SPC\udcontrol limits.\udThe paper is organized as follows: section 2 briefly presents SPC concepts and its\udpeculiarities; section 3 discusses the main differences and lacks of SPC for software and\udpresents the approach proposed by the authors; finally, in section 4 conclusions are drawn.
展开▼
